0% found this document useful (0 votes)
81 views

Netfilter

Uploaded by

clubmailus
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
81 views

Netfilter

Uploaded by

clubmailus
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

Netfilter

Netfilter is a framework provided by the Linux kernel that allows


various networking-related operations to be implemented in the Netfilter
form of customized handlers. Netfilter offers various functions and Stable release 5.14.10[1] / 7
operations for packet filtering, network address translation, and October 2021
port translation, which provide the functionality required for
Preview release 5.15-rc4[2] /
directing packets through a network and prohibiting packets from
3 October
reaching sensitive locations within a network.
2021
Netfilter represents a set of hooks inside the Linux kernel, allowing Written in C
specific kernel modules to register callback functions with the
Operating system Linux
kernel's networking stack. Those functions, usually applied to the
traffic in the form of filtering and modification rules, are called for Type Linux kernel
every packet that traverses the respective hook within the module
networking stack.[3]
Packet
filter/firewall
License GNU GPL
Contents
Website netfilter.org (htt
History ps://netfilter.or
Userspace utility programs g)
iptables
nftables
Packet defragmentation
Connection tracking
Connection tracking helpers
Network address translation
NAT helpers
Further Netfilter projects
conntrack-tools
ipset
SYN proxy
ulogd
Userspace libraries
Netfilter workshops
See also
References
External links

History
Rusty Russell started the netfilter/iptables project in
1998; he had also authored the project's predecessor,
ipchains. As the project grew, he founded the Netfilter
Core Team (or simply coreteam) in 1999. The
software they produced (called netfilter hereafter) uses
the GNU General Public License (GPL) license, and
in March 2000 it was merged into version 2.4.x of the
Linux kernel mainline.

In August 2003 Harald Welte became chairman of the


coreteam. In April 2004, following a crack-down by Relation of (some of) the different Netfilter
the project on those distributing the project's software components
embedded in routers without complying with the
GPL, a German court granted Welte an historic
injunction against Sitecom Germany, which refused to follow the GPL's terms (see GPL-related disputes).
In September 2007 Patrick McHardy, who led development for past years, was elected as new chairman of
the coreteam.

Prior to 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 alter the networking code so they can manipulate packets, as Linux kernel lacked a general
packets control framework until the introduction of Netfilter.

Whereas ipchains and ipfwadm combine packet filtering and NAT (particularly three specific kinds of
NAT, called masquerading, port forwarding, and redirection), Netfilter separates packet operations into
multiple parts, described below. Each connects to the Netfilter hooks at different points to access packets.
The connection tracking and NAT subsystems are more general and more powerful than the rudimentary
versions within ipchains and ipfwadm.

In 2017 IPv4 and IPv6 flow offload infrastructure was added, allowing a speedup of software flow table
forwarding and hardware offload support.[4][5]

Userspace utility programs

Flow of network packets through Netfilter with legacy iptables packet filtering

iptables(8) (https://man.cx/?page=iptables(8))
ip6tables(8) (https://man.cx/?page=ip6tables(8))
ebtables(8) (https://man.cx/?page=ebtables(8))
arptables(8) (https://man.cx/?page=arptables(8))
ipset(8) (https://man.cx/?page=ipset(8))
nftables(8) (https://man.cx/?page=nftables(8))

iptables

The kernel modules named ip_tables, ip6_tables, arp_tables (the underscore is part of the
name), and ebtables comprise the legacy packet filtering portion of the Netfilter hook system. They
provide a table-based system for defining firewall rules that can filter or transform packets. The tables can
be administered through the user-space tools iptables, ip6tables, arptables, and
ebtables. Notice that although both the kernel modules and userspace utilities have similar names, each
of them is a different entity with different functionality.

Each table is actually its own hook, and each table was introduced to serve a specific purpose. As far as
Netfilter is concerned, it runs a particular table in a specific order with respect to other tables. Any table can
call itself and it also can execute its own rules, which enables possibilities for additional processing and
iteration.

Rules are organized into chains, or in other words, "chains of rules". These chains are named with
predefined titles, including INPUT, OUTPUT and FORWARD. These chain titles help describe the origin in
the Netfilter stack. Packet reception, for example, falls into PREROUTING, while the INPUT represents
locally delivered data, and forwarded traffic falls into the FORWARD chain. Locally generated output passes
through the OUTPUT chain, and packets to be sent out are in POSTROUTING chain.

Netfilter modules not organized into tables (see below) are capable of checking for the origin to select their
mode of operation.

iptable_raw module
When loaded, registers a hook that will be called before any other Netfilter hook. It
provides a table called raw that can be used to filter packets before they reach more
memory-demanding operations such as Connection Tracking.
iptable_mangle module
Registers a hook and mangle table to run after Connection Tracking (see below) (but still
before any other table), so that modifications can be made to the packet. This enables
additional modifications by rules that follow, such as NAT or further filtering.
iptable_nat 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 afterwards. The network address translation table (or
"nat") that is made available to iptables is merely a "configuration database" for NAT
mappings only, and not intended for filtering of any kind.
iptable_filter module
Registers the filter table, used for general-purpose filtering (firewalling).
security_filter module
Used for Mandatory Access Control (MAC) networking rules, such as those enabled by the
SECMARK and CONNSECMARK targets. (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 following the call of the filter table,
allowing any Discretionary Access Control (DAC) rules in the filter table to take effect
before any MAC rules. This table provides the following built-in chains: INPUT (for
packets coming into the computer itself), OUTPUT (for altering locally-generated packets
before routing), and FORWARD (for altering packets being routed through the computer).
nftables

nftables is the new packet-filtering portion of Netfilter. nft is the new userspace utility that replaces
iptables, ip6tables, arptables and ebtables.

nftables kernel engine adds a simple virtual machine into the Linux kernel, which is able to execute
bytecode to inspect a network packet and make decisions on how that packet should be handled. The
operations implemented by this virtual machine are intentionally made basic: it can get data from the packet
itself, have a look at the associated metadata (inbound interface, for example), and manage connection
tracking data. Arithmetic, bitwise and comparison operators can be used for making decisions based on that
data. The virtual machine is also capable of manipulating sets of data (typically IP addresses), allowing
multiple comparison operations to be replaced with a single set lookup.[6]

This is in contrast to the legacy Xtables (iptables, etc.) code, which has protocol awareness so deeply built
into the code that it has had to be replicated four times—for IPv4, IPv6, ARP, and Ethernet bridging—as
the firewall engines are too protocol-specific to be used in a generic manner.[6] The main advantages over
iptables are simplification of the Linux kernel ABI, reduction of code duplication, improved error
reporting, and more efficient execution, storage, and incremental, atomic changes of filtering rules.

Packet defragmentation
The nf_defrag_ipv4 module will defragment IPv4 packets before they reach Netfilter's connection
tracking (nf_conntrack_ipv4 module). This is necessary for the in-kernel connection tracking and
NAT helper modules (which are a form of "mini-ALGs") that only work reliably on entire packets, not
necessarily on fragments.

The IPv6 defragmenter is not a module in its own right, but is integrated into the
nf_conntrack_ipv6 module.

Connection tracking
One of the important features built on top of the Netfilter framework is connection tracking.[7] Connection
tracking allows the kernel to keep track of all logical network connections or sessions, and thereby relate all
of the packets which may make up that connection. NAT relies on this information to translate all related
packets in the same way, and iptables can use this information to act as a stateful firewall.

The connection state however is completely independent of any upper-level state, such as TCP's or SCTP's
state. Part of the reason for this is that when merely forwarding packets, i.e. no local delivery, the TCP
engine may not necessarily be invoked at all. Even connectionless-mode transmissions such as UDP, IPsec
(AH/ESP), GRE and other tunneling protocols have, at least, a pseudo connection state. The heuristic for
such protocols is often based upon a preset timeout value for inactivity, after whose expiration a Netfilter
connection is dropped.

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; for TCP/UDP it is
the port numbers, for tunnels it can be their tunnel ID, but otherwise is just zero, as if it were not part of the
tuple. To be able to inspect the TCP port in all cases, packets will be mandatorily defragmented.

Netfilter connections can be manipulated with the user-space tool conntrack.


iptables can make use of checking the connection's information such as states, statuses and more to
make packet filtering rules more powerful and easier to manage. The most common states are:

NEW
trying to create a new connection
ESTABLISHED
part of an already-existing connection
RELATED
assigned to a packet that is initiating a new connection and which has been "expected";
the aforementioned mini-ALGs set up these expectations, for example, when the
nf_conntrack_ftp module sees an FTP "PASV" command
INVALID
the packet was found to be invalid, e.g. it would not adhere to the TCP state diagram
UNTRACKED
a special state that can be assigned by the administrator to bypass connection tracking for
a particular packet (see raw table, above).

A normal example would be that the first packet the conntrack subsystem sees will be classified "new", the
reply would be classified "established" and an ICMP error would be "related". An ICMP error packet
which did not match any known connection would be "invalid".

Connection tracking helpers

Through the use of plugin modules, connection tracking can be given knowledge of application-layer
protocols and thus understand that two or more distinct connections are "related". For example, consider
the FTP protocol. A control connection is established, but whenever data is transferred, a separate
connection is established to transfer it. When the nf_conntrack_ftp module is loaded, the first
packet of an FTP data connection will be classified as "related" instead of "new", as it is logically part of an
existing connection.

The helpers only inspect one packet at a time, so if vital information for connection tracking is split across
two packets, either due to IP fragmentation or TCP segmentation, the helper will not necessarily recognize
patterns and therefore not perform its operation. IP fragmentation is dealt with the connection tracking
subsystem requiring defragmentation, though TCP segmentation is not handled. In case of FTP,
segmentation is deemed not to happen "near" a command like PASV with standard segment sizes, so is not
dealt with in Netfilter either.

Network address translation


Each connection has a set of original addresses and reply addresses, which initially start out the same. NAT
in Netfilter is implemented by simply changing the reply address, and where desired, port. When packets
are received, their connection tuple will also be compared against the reply address pair (and ports). Being
fragment-free is also a requirement for NAT. (If need be, IPv4 packets may be refragmented by the normal,
non-Netfilter, IPv4 stack.)

NAT helpers

Similar to connection tracking helpers, NAT helpers will do a packet inspection and substitute original
addresses by reply addresses in the payload.
Further Netfilter projects
Though not being kernel modules that make use of Netfilter code directly, the Netfilter project hosts a few
more noteworthy software.

conntrack-tools

conntrack-tools is a set of user-space tools for Linux that allow system administrators to interact
with the Connection Tracking entries and tables. The package includes the conntrackd daemon and the
command line interface conntrack. The userspace daemon conntrackd can be used to enable high
availability cluster-based stateful firewalls and collect statistics of the stateful firewall use. The command
line interface conntrack provides a more flexible interface to the connection tracking system than the
obsolete /proc/net/nf_conntrack.

ipset

Unlike other extensions such as Connection Tracking, ipset[8] is more related to iptables than it is
to the core Netfilter code. ipset does not make use of Netfilter hooks for instance, but actually provides
an iptables module to match and do minimal modifications (set/clear) to IP sets.

The user-space tool called ipset is used to set up, maintain and inspect so called "IP sets" in the Linux
kernel. An IP set usually contains a set of IP addresses, but can also contain sets of other network numbers,
depending on its "type". These sets are much more lookup-efficient than bare iptables rules, but of
course may come with a greater memory footprint. Different storage algorithms (for the data structures in
memory) are provided in ipset for the user to select an optimum solution.

Any entry in one set can be bound to another set, allowing for sophisticated matching operations. A set can
only be removed (destroyed) if there are no iptables rules or other sets referring to it.

SYN proxy

SYNPROXY target makes handling of large SYN floods possible without the large performance penalties
imposed by the connection tracking in such cases. By redirecting initial SYN requests to the SYNPROXY
target, connections are not registered within the connection tracking until they reach a validated final ACK
state, freeing up connection tracking from accounting large numbers of potentially invalid connections. This
way, huge SYN floods can be handled in an effective way.[9]

On 3 November 2013, SYN proxy functionality was merged into the Netfilter, with the release of version
3.12 of the Linux kernel mainline.[10][11]

ulogd

ulogd is a user-space daemon to receive and log packets and event notifications from the Netfilter
subsystems. ip_tables can deliver packets via the userspace queueing mechanism to it, and connection
tracking can interact with ulogd to exchange further information about packets or events (such as
connection teardown, NAT setup).
Userspace libraries

Netfilter also provides a set of libraries having libnetfilter as a prefix of their names, that can be
used to perform different tasks from the userspace. These libraries are released under the GNU GPL
version 2. Specifically, they are the following:

libnetfilter_queue
allows to perform userspace packet queueing in conjunction with iptables; based on
libnfnetlink
libnetfilter_conntrack
allows manipulation of connection tracking entries from the userspace; based on
libnfnetlink
libnetfilter_log
allows collection of log messages generated by iptables; based on libnfnetlink
libnl-3-netfilter
allows operations on queues, connection tracking and logs; part of the libnl project[12]
libiptc
allows changes to be performed to the iptables firewall rulesets; it is not based on any
netlink library, and its API is internally used by the iptables utilities
libipset
allows operations on IP sets; based on libmnl.

Netfilter workshops
The Netfilter project organizes an annual meeting for developers, which is used to discuss ongoing research
and development efforts. The 2018 Netfilter workshop took place in Berlin, Germany, in June 2018.[13]

See also
Berkeley Packet Filter
IP Virtual Server (IPVS, part of LVS)
ipchains, the predecessor to iptables
ipfw
Linux Virtual Server (LVS)
Netlink, an API used by Netfilter extensions
Network scheduler, another low-level component of the network stack
NPF (firewall)
PF (firewall)
Uncomplicated Firewall

References
1. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/?h=v5.14.10.
2. Linus Torvalds (3 October 2021). "Linux 5.15-rc4" (https://lore.kernel.org/lkml/CAHk-=wifo=o
[email protected]/). Retrieved 5 October
2021.
3. "netfilter/iptables project homepage - The netfilter.org project" (https://www.netfilter.org/).
netfilter.org. Retrieved 2014-07-04.
4. "Flow offload infrastructure" (https://lwn.net/Articles/738214/). LWN.net.
5. "Flow offload infrastructure" (https://lwn.net/Articles/742164/). LWN.net.
6. Jonathan Corbet (2013-08-20). "The return of nftables" (https://lwn.net/Articles/564095/).
LWN.net. Retrieved 2013-10-22.
7. Neira Ayuso, Pablo (14 June 2006). "Netfilter's Connection Tracking System" (https://people.
netfilter.org/pablo/docs/login.pdf) (PDF).
8. "IP sets" (http://ipset.netfilter.org/). ipset.netfilter.org. Retrieved 2014-07-04.
9. Patrick McHardy (2013-08-07). "netfilter: implement netfilter SYN proxy" (https://lwn.net/Articl
es/563151/). LWN.net. Retrieved 2013-11-05.
10. "netfilter: add SYNPROXY core/target" (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linu
x.git/commit/?id=48b1de4c110a7afa4b85862f6c75af817db26fad). kernel.org. 2013-08-27.
Retrieved 2013-11-05.
11. "netfilter: add IPv6 SYNPROXY target" (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linu
x.git/commit/?id=4ad362282cb45bbc831a182e45637da8c5bd7aa1). kernel.org. 2013-08-
27. Retrieved 2013-11-05.
12. "Netfilter Library (libnl-nf)" (https://www.infradead.org/~tgr/libnl/doc/api/group__nfnl.html).
infradead.org. 2013-04-02. Retrieved 2013-12-28.
13. "14th Netfilter Workshop" (https://workshop.netfilter.org/2018/). workshop.netfilter.org. 2018-
09-26. Retrieved 2018-09-26.

External links
Official website (https://netfilter.org/)
conntrack-tools homepage (https://netfilter.org/projects/conntrack-tools/)
ipset homepage (http://ipset.netfilter.org/)
ulogd homepage (https://netfilter.org/projects/ulogd/)
Home of the Netfilter Workshop websites (https://workshop.netfilter.org/)
"Writing Netfilter Modules (https://inai.de/documents/Netfilter_Modules.pdf)" (e-book; 2009)
"Netfilter and Iptables — Stateful Firewalling for Linux (https://www.zdnet.com/news/netfilter-
and-iptables-stateful-firewalling-for-linux/296775)" (11 October 2001)
Network overview by Rami Rosen (https://web.archive.org/web/20121019131903/http://ww
w.linuxfoundation.org/collaborate/workgroups/networking/networkoverview)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Netfilter&oldid=1045788206"

This page was last edited on 22 September 2021, at 13:06 (UTC).

Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using
this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia
Foundation, Inc., a non-profit organization.

You might also like